Перейти к основному содержимому

Теоретические основы CMS

· 6 мин. чтения

CMS matrix и отечественный CMSlist предлагают огромные списки доступных opensource систем управления сайтами. Многие из них имеют множество недостатков, такие как

  • Монстроидальность и неверное useability. 80% функций для неискушённого пользователя наврядли будут использоваться. А из оставшихся 20% сразу он поймёт как работает 1%.
  • Устаревший код и архитектура со времён PHP4, необходимость версионной поддержки
  • Медленная скорость загрузки из-за подгрузки неиспользуемых объектов и модулей
  • Чёткая полоса возможностей системы, ограничивающая как что должно работать, либо наоборот - её отсутсвие служит и дорогой и препятствием, особенно для новичков

Всё это заставляет программистов писать свою систему с нуля. Я постараюсь тут описать некоторые теоретические основы для этих начинаний и как итог - к чему они все приходят.

Framework​

Всё начинается с платформы, т.е. расширение языка функциями и объектами, использование которых значительно облегчит дальнейшую систему. На данный момент основные законодатели мод на PHP:

Форма следует за функцией
Луи Салливан, американский архитектор, "отец модернизма"

На других менее популярных языках фреймворки соответсвенно Python - Plone, Java - Spring, Struts

Выбор из существующей платформы как и выбор CMS - палка с двумя концами. Написав свою вы будете уверены что всё работает как вы задумали и не надо будет изучать API существующей. В то же время своя платформа как правило отметает поддержку третьими разработчиками (потому что документацию как правило никто не успевает написать).

Платформа по разному может запускать инициализацию объектов, по-разному хранить данные и файлы и как правило отвечают за

  • Разделение логики исполняемого кода по MVC
  • Кэширование (объектов и темплейтов)
  • ЧПУ (Умные URL)
  • Кодировку текста (UTF8) и тип данных (MIME)
  • Упрощённый/абстрагированный доступ к БД (PEAR DB2, ADO DB)
  • Адрессацию и запуск более высоких уровней приложения
  • Автогенерацию форм, таблиц БД, страниц управления (Scaffolding)
  • Классы генерации деревьев, особых форматов данных (XML, json)

Эволюция и скорость​

Если сравнивать уровень развития архитектуры CMS с живыми организмами, то можно заметить что эволюция заставляет животных приспосабливаться изменяя их форму тела и социальное поведение. Системы CMS тоже могут либо быть примитивными и очень быстрыми, громадными вымирающими всеядными динозаврами, узконишевыми скатами не имеющими конкурентов либо балансирующими всем в меру. Однако надо сразу понимать что обязательно найдётся движок чем-то лучше и если вы делаете один выбор (скажем использовать только файловую систему), то приобретаете и проигрываете одновременно в скорости запуска или в лёгкости разработки.

Управление содержанием​

После выбора платформы, разработчики и архитекты по разному решают проблему управления содержанием. Есть два основных пути:

  • Наглядное управление. Меню, статьи и всё редактируется в том же дизайне что и весь сайт. Элементы управления при этом видны привелигированным пользователям. Плюс такой реализации в лёгкости понимания - клиент видит статью, нажимает иконку и тут же редактирует содержимое.
  • Админпанель. Параллельно с публичной частью создаётся панель управления, разделяемая на модули. Модульность наглядно демонстрирует расширяемость, центральная система авторизации гарантирует меньшую степень риска в доступе к закрытым данным и более лёгкую работу программисту.

Иерархичная структура меню создаётся либо в уникальном табличном экземпляре, либо (что реже) в отдельных таблицах.  В старых (и быстрых) CMS, меню можно встретить в виде массивов прописанных сразу в php-файлах, в таком случае можно ожидать что языки и переводы сделаны так же.

Модули и фундаментальные вопросы архитектуры​

Фактическое содержание той или иной страницы как правило зависит от модуля - отдельного класса/файла который реализует бизнес-логику, хранит свои данные. Оценить сложность движка а заодно и опустить архитектора можно задав фундаментальные вопросы:

  • Может ли клиент на одной странице создать две работающих контактных формы (или две статьи)? Обычно ответ - нет, поскольку со страницей связан как правило только один модуль (скажем "текст", "опрос", "контакт", "ЧаВо"). Если нельзя, то как бы пришлось это решать в обходном варианте.
  • Могут ли данные существовать независимо от существования страницы? Какие?
  • Может ли содержание существовать (и изменяться) сразу на нескольких страницах?
  • Могут ли разные пользователи одновременно менять содержание без потерь? Есть ли версионность и синхронизация изменений?
  • Можно ли объекты встраивать (inline/embed) в содержание страницы с помощью WYSIWYG редактора? А динамически ссылаться между собой с автообновлением или автоудалением?
  • Как хранятся данные страниц в зависимости от их модуля - в одной общей таблице или каждый раз в разной таблице? Последний вариант плохо масштабируется если надо нарисовать меню.
  • Где хранить, как показывать и обновлять ресурсы модулей (js, img, css) и ресурсы добавленные пользователями? Что важней при доступе к файлам - модульность или типизация файлов?
  • Какие модули зависят от языка, а у каких содержание для всех языков одинаково?
  • Как по умолчанию создаются права к объектам - "всё разрешено" или "всё запрещено"?

Отвечать на первый вопрос по-моему можно двумя путями:

  • Выбираемые под каждую страницу шаблоны и smarty-функциями (вызываемые напрямую из темплейта) - не самое лучшее решение из-за смешивания представления и трудности дебага
  • Связкой 1:n между страницей и модулями. Усложняет архитектуру, внося внутреннюю адрессацию под компоненты (widgets)

Среды разработки и поддержка версий​

При написании системы всегда нужны несколько сред для правильного процесса разработки:

  1. Dev - то где вы пишите код и сразу тестируете. Очень неплохо иметь на localhost под LAMP-пакетом типа Easyphp, Apache2triad, WAMP и тп.
  2. Prelive - среда для всех разработчиков внутри компании и тестеров. Иногда её разделяют для тестеров отдельно, иногда комбинируют как-то с ядром движка из SVN
  3. Production/Live - собственно финальная стадия с реальными данными. Заставить программистов не работать напрямую с этой средой - тяжко.

Тут мы доходим до проблемы синхронизации данных и кода т.е. обновлением движка. Тут есть два пути - продать клиенту кота в мешке, получить деньги и больше с ним не связываться, не обновлять движок вообще но это как правило нереально и со временем может получиться что у вас 100 клиентов, три кардинальных версий cms и одна головная боль с поддержкой старых версий.

Получается что должна быть постоянно обновляющаяся часть движка, постоянная публичная часть и система обновлений. Автообновление может быть значительно упрощено если все проекты лежат на вашем хостинге.

API, документация, защита​

Не стоит забывать о документации. Вы можете написать идеальную CMS, с множеством функций облегчающих жизнь, но без описаний как что можно использовать, без комментариев к функциям или смысла модулей невозможно новому человеку понять что происходит.

Некоторые компании специализируются именно на разработке собственной CMS, перепродавая её использование третьим фирмам и берутся за реализацию только богатых клиентов. Поскольку надеятся на благонадёжность клиентов-разработчиков не приходится, то ядро системы шифруется через Zend Guard или Ion Cube.

Читайте: